Process control systems, such as distributed or scalable process control systems like those used in chemical, petroleum or other processes, typically include one or more process controllers communicatively coupled to each other, to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, and uses this information to implement a control routine to generate control signals which are sent over the buses to the field devices to control the operation of the process. Information from the field devices and the controller is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc.
Typically, a process control system operates within a business enterprise that may include several process plants, component and/or service suppliers and customers, all of which may be distributed throughout a large geographic area, or in some cases, throughout the world. The process plants, suppliers and customers may communicate with each other using a variety of communication media and technologies or platforms such as, for example, the Internet, satellite links, ground-based wireless transmissions, telephone lines, etc. Of course, the Internet has become a preferred communication platform for many business enterprises because the communications infrastructure is established, making the communication infrastructure costs for an enterprise near zero, and the technologies used to communicate information via the Internet are well-understood, stable, secure, etc.
Each process control plant within an enterprise may include one or more process control systems as well as a number of other business-related or information technology systems, which are needed to support or maintain or which are complementary to the operation of the process control systems. In general, the information technology systems within a process control plant may include manufacturing execution systems such as, for example, a maintenance management system and may also include enterprise resource planning systems such as, for example, scheduling, accounting and procurement systems. Although these information technology systems may be physically located within or near a plant, in some cases a few or possibly all of these systems may be remotely located with respect to the plant and may communicate with the plant using the Internet or any other suitable communication link. System engineers and other personnel responsible for maintaining the hardware and software associated with the process control system may be subject to travel to the different plant sites. Moreover, maintaining hardware and software at even a single process control system is an arduous task.
Independent remote maintenance systems have been developed to remotely monitor process control systems, including multiple process control systems within an enterprise, and process control systems for multiple enterprises. An example of a remote maintenance system is disclosed in U.S. Pat. No. 7,698,242 entitled “Systems and Method to Maintain Process Control Systems Using Information Retrieved From a Database Storing General-Type Information and Specific-Type Information,” the contents of which are expressly incorporated by reference herein. In particular, the remote maintenance systems help maintain the hardware and software of the process control system by identifying, and informing the system engineers of, various risk factors (also referred to as risk indicators) relevant to the process control system, such as, for example, knowledge base articles (KBAs) describing issues the process control system may encounter, software updates (e.g., hotfixes, security, etc.), action alerts, service call activities, and hardware/software product lifecycles (e.g., age, version, backwards compatibility, forward compatibility, etc.). Thus, the system engineer is informed of potential risks to the availability, reliability and security of the process control system, thereby helping the system engineer to undertake preventative actions to avoid problems with the process control system, as well as alleviate the burden of travelling from one site to another.
Of course, it remains the responsibility of the system engineer or other appropriate maintenance personnel to read a knowledge base article, install a software update, close an open action alert or close an open service call in order to address the risks to the process control system. However, due to the complexity of many of these process control systems, the system engineer is often inundated with numerous KBAs, software updates, action alerts, service calls, product lifecycles and other risk factors each day. As these risk factors accumulate, the overall risk to the process control system increases and the overall health of the process control system degrades. At a personnel level, the system engineers or other maintenance personnel would sometimes need motivation to take preventative measures, rather than reactionary measures.
In order to address this problem, the remote maintenance systems objectively scored the health of each process control system based on the KBAs, software updates, action alerts, service calls, product lifecycles and other risk factors for that process control system. For example, unread KBAs, uninstalled software updates, open action alerts, open service calls and obsolete, unsupported hardware/software would decrease a process control system's health score, whereas read KBAs, installed software updates, closed (or undertaken) action alerts, closed (or undertaken) service calls and current or actively supported hardware/software would increase the health score. Generally speaking, the total number of risk factors were added and scaled to fixed range (e.g., between 1 and 10). This health score, and the website, were updated periodically (e.g., daily) as new risk factors arose.
The remote maintenance systems further supported a secure support website using a portal type of webpage providing links to the health score, risk factors, maintenance information, maintenance features and maintenance services for the process control system provided by the remote monitoring system. For example, each process control system was registered with the remote maintenance system which included configuration information associated with process control systems monitored by the remote maintenance system. The configuration information could include field device information, software information, firmware information, operational status information, maintenance information, lifecycle information, etc. associated with hardware, software, and/or firmware used to implement the components and devices of monitored process control systems. The remote maintenance system would thereby know the (typically unique) configuration of each registered process control system, including the process control system's content, such as software, hardware, licenses, applied software updates, software versions, etc., and match the process control system's content to relevant risk factors. Once registered, a system engineer could access the website from a workstation, tablet, smartphone or other computing device in order to view information about the process control system, including the health score.
Furthermore, the support website allowed the system engineer to update the status of any risk factors identified by the remote maintenance system. For example, the website may allow the system engineer to note that a KBA has been read, a software update has been installed, an action alert has been closed, a service call has been closed, etc. Alternatively, the remote maintenance system could automatically detect when a KBA is read (e.g., detect when the file has been opened or downloaded), when a software update has been installed (e.g., the update has been downloaded or installation executed), or when an action alert or service call has been closed (e.g., status of the process control system's or enterprise's internal maintenance support system indicates a work team has address the problem, parts have been ordered, a work order has been generated, etc.). Thus, the remote maintenance system would know whether a risk factor had been eliminated (e.g., the risk was addressed). A more detailed explanation of an exemplary support website is provided in U.S. Pat. No. 7,698,242 referred to above.
However, despite this attempt to motivate system engineers to take preventative measures to address risks to the process control system and avoid problems, the health scores were largely ignored, because process control system health management, in terms of the systematic elimination of risks to system reliability, security and performance, was/is an ongoing process. For example, Microsoft® regularly issues new security updates for its products, which, in turn, are tested by Emerson Process Management for compatibility with its process control systems, such as the DeltaV™ control system, sold by Emerson Process Management. In addition, service calls received from process control systems, which included process control systems worldwide, would be evaluated by the remote maintenance system, which, in turn, would lead to new or revised KBAs and/or software updates. Over longer periods of time, advances in technology led to new operating systems, new computers, new hardware and software offerings, which made their way into existing systems through expansions, migrations and modernization projects. In short, the change for a process control system is constant, which creates a backlog to risk elimination activity as new risk factors were introduced daily. This made it nearly impossible for a process control system to receive an acceptable health score, despite a system engineer's best efforts. New risk factors would be continuously introduced even before a system engineer had sufficient opportunity to address and eliminate them, which drove down the health score for the process control system. In turn, this led the system engineer to ignore the health score, and to underutilize the remote maintenance system, which led to an even greater backlog of risk factors and risk elimination activities. Thus, there is a need for an effective, sustained and measurable process control system health management.